[lldb] [cmake] Fix delayloading liblldb.dll in mingw builds #162831
Conversation
ec28b95 made liblldb delayloaded, but the supplied command line parameter is only valid for MSVC style builds. For mingw builds using LLD, we can easily pass a similar option. For mingw builds with ld.bfd, we can't quite as easily delayload it - for these cases, just keep linking it like we usually do, and warn if the user tried to set LLDB_PYTHON_DLL_RELATIVE_PATH in a build where it won't have any effect. Also change the setting for MSVC style builds, to use the simpler `$<TARGET_FILE_NAME:liblldb>` instead of `$<TARGET_FILE_BASE_NAME:liblldb>.dll`. The former pattern is what we use for mingw targets, and it makes the code clearer to use that for both, as that same expression should do the right thing for both.
|
@llvm/pr-subscribers-lldb Author: Martin Storsjö (mstorsjo) Changesec28b95 made liblldb delayloaded, but the supplied command line parameter is only valid for MSVC style builds. For mingw builds using LLD, we can easily pass a similar option. For mingw builds with ld.bfd, we can't quite as easily delayload it - for these cases, just keep linking it like we usually do, and warn if the user tried to set LLDB_PYTHON_DLL_RELATIVE_PATH in a build where it won't have any effect. Also change the setting for MSVC style builds, to use the simpler Full diff: https://github.com/llvm/llvm-project/pull/162831.diff 1 Files Affected:
diff --git a/lldb/cmake/modules/AddLLDB.cmake b/lldb/cmake/modules/AddLLDB.cmake
index bdd6f73238422..5d58abf237f58 100644
--- a/lldb/cmake/modules/AddLLDB.cmake
+++ b/lldb/cmake/modules/AddLLDB.cmake
@@ -170,7 +170,19 @@ function(add_lldb_executable name)
if(WIN32)
list(FIND ARG_LINK_LIBS liblldb LIBLLDB_INDEX)
if(NOT LIBLLDB_INDEX EQUAL -1)
- target_link_options(${name} PRIVATE "/DELAYLOAD:$<TARGET_FILE_BASE_NAME:liblldb>.dll")
+ if (MSVC)
+ target_link_options(${name} PRIVATE "/DELAYLOAD:$<TARGET_FILE_NAME:liblldb>")
+ elseif (MINGW AND LINKER_IS_LLD)
+ # LLD can delay load just by passing a --delayload flag, as long as the import
+ # library is a short type import library (which LLD and MS link.exe produce).
+ # With ld.bfd, with long import libraries (as produced by GNU binutils), one
+ # has to generate a separate delayload import library with dlltool.
+ target_link_options(${name} PRIVATE "-Wl,--delayload=$<TARGET_FILE_NAME:liblldb>")
+ elseif (DEFINED LLDB_PYTHON_DLL_RELATIVE_PATH)
+ # If liblldb can't be delayloaded, then LLDB_PYTHON_DLL_RELATIVE_PATH will not
+ # have any effect.
+ message(WARNING "liblldb is not delay loaded, LLDB_PYTHON_DLL_RELATIVE_PATH has no effect")
+ endif()
endif()
endif()
if(CLANG_LINK_CLANG_DYLIB)
|
3 participants
ec28b95 made liblldb delayloaded, but the supplied command line parameter is only valid for MSVC style builds.
For mingw builds using LLD, we can easily pass a similar option. For mingw builds with ld.bfd, we can't quite as easily delayload it - for these cases, just keep linking it like we usually do, and warn if the user tried to set LLDB_PYTHON_DLL_RELATIVE_PATH in a build where it won't have any effect.
Also change the setting for MSVC style builds, to use the simpler
$<TARGET_FILE_NAME:liblldb>instead of$<TARGET_FILE_BASE_NAME:liblldb>.dll. The former pattern is what we use for mingw targets, and it makes the code clearer to use that for both, as that same expression should do the right thing for both.